…Electron"

The harness hardcoded ~/Library/Application Support/Electron, but the leaf of
app.getPath("userData") is app.getName() — "openscreen" in dev, the
productName once packaged. "Electron" is only what a bare `electron .` with
no app name uses, so the default pointed somewhere the app never writes. Probe
the plausible names and take the one that exists.

transcript.whisperHint told users "runs in your browser". Whisper runs in the
main process: SttManager spawns the native whisper-stt-server helper
(whisper.cpp linked statically) and talks to it over loopback HTTP. The renderer
only ships it audio and maps the result back. See
technical-documentation/architecture/transcription-and-captions.md.

Reworded to "runs on your computer" (and the per-language equivalent) across all
13 locales. The "no data leaves the device" half was already accurate and is
untouched — as is the rest of each sentence, since only the offending clause was
replaced. "computer" rather than "device" because the second half already says
data never leaves the device, and repeating it reads as a stutter in most of
these languages.

Only whisperHint made the claim; nothing else in the locales, the docs or the
website says transcription is a browser feature.

npm run i18n:check passes; the diff is 13 lines across 13 files.

… invisible

On macOS 26, a window that has had setContentProtection(true) applied is never
displayed. Not "excluded from screen captures", which is the documented
behaviour and the reason we call it — never painted for the user either. The app
started with a tray icon, a healthy renderer and no window on screen, and both
the tray click and Cmd+Shift+O were inert because Electron already considered
the window visible.

Confirmed on macOS 26.5 / Electron 41.2.1 against the HUD: ready-to-show fired,
show() was called, geometry was on-screen on the main display, React had mounted
with no console errors. Unsetting protection makes it appear instantly.
Reordering protect-vs-show changes nothing, so it is the call itself, not the
timing.

setContentProtection maps to NSWindow.sharingType = NSWindowSharingNone, a path
Electron has churned on repeatedly (electron/electron#45990; PR #46886 reverted
a macOS content-protection refactor).

Gated on the macOS major version, not darwin wholesale: the breakage is only
confirmed on 26.x, and dropping protection on older macOS where it may work
would be a privacy regression made on no evidence. The check reads
process.getSystemVersion() (macOS "26.5.0"), NOT os.release() (Darwin "25.5.0")
— feeding it the latter would silently never match.

OPENSCREEN_FORCE_CONTENT_PROTECTION=1 re-enables it to re-test against a future
Electron.

KNOWN TRADE-OFF: the HUD and Notes windows can now appear in captures on macOS
26. Apple already made that partly unavoidable — ScreenCaptureKit ignores
sharingType, so any SCK-based recorder captures them regardless, including our
own helper. The durable fix is to exclude our windows via SCContentFilter's
excludingWindows:, which electron/native/screencapturekit currently passes as
[]. Not done here: it needs a recording to verify, which needs screen tooling I
don't have in this session.

…inverted ranges

Verified against a real 24.7s French screen recording (WER-free run: 10 segments,
57 words, fr detected, rtf 0.076 on M1/Metal).

Two problems with the single bundled `every()`:

- It could not say which property broke. The real clip tripped it and the output
  read "word times lie within the clip — clip is 24.70s" when nothing was outside
  the clip: max word end was 24.00s. The actual trigger was `end < start` on
  three tokens.

- Asserting `end >= start` on the raw helper response is wrong for this layer.
  whisper.cpp gives a segment's last word the segment's own t1 as its end, while
  the word's DTW start runs 80-150ms late, so a token emitted near the boundary
  (standalone punctuation: "?", "!", "!") lands after it and inverts. That is
  anticipated and handled one layer up, on purpose — whisperServer.ts clamps to
  Math.max(startSec + 0.02, endSec), and snapWordBoundaries.ts keeps "degenerate
  words (whisper sometimes reports end <= start) non-empty". The document never
  sees an inverted range.

Now three separate checks (starts non-negative, ends within clip, starts
monotonic) plus an informational count of raw inversions.

…r addon

cargo stamps the cdylib's own id (LC_ID_DYLIB) with the absolute path it was
built at — crates/target/release/deps/libcompositor_view.dylib. That is not a
load failure: require() dlopens the .node by path and never reads LC_ID_DYLIB,
and every real dependency was already rewritten to @rpath. But it ships a
build-machine path inside a release artefact, complete with the builder's home
directory and checkout name, which defeats reproducible builds and leaks a
filesystem layout to anyone running `otool -D` on the installed app.

Set it to @rpath/compositor_view.node and re-sign.

The existing post-condition could not have caught it: it grepped otool -L output
for `lib(av|sw)` only, so it saw neither the id nor any future non-ffmpeg
dependency arriving absolute. Replaced with the real invariant — no reference,
id or dependency, may be an absolute path outside /usr/lib and /System — and it
now runs over the vendored dylibs too, not just the addon.

Verified: shipped copy's id is @rpath/compositor_view.node with a valid
signature; the dev copy under electron/native/compositor-view/build/ still
carries its absolute id, which the new check correctly identifies as the value
it would reject (that copy never leaves the checkout, by design).

….app

The macOS CI job built the ScreenCaptureKit helper and staged the whisper-stt
binaries, but never ran fetch:ffmpeg:mac or build:native:compositor:mac. So the
.app it produced had no compositor_view.node at all: preview and export dead in
the installed app, with nothing in any log to say why. Windows does not drift
this way because its job just runs `npm run build:win`, which chains both; the
macOS job spells its steps out (it needs --dir plus a hand-rolled DMG and
signing) and fell behind the `build:mac` recipe it was supposed to mirror.

Nothing caught it, because before-pack.cjs — the hook written precisely to stop
a broken compositor shipping — returned early on every non-win32 platform.

Two changes:

- build.yml gains the two missing steps, both cached: the LGPL ffmpeg tree
  (built from source, ~5 min, keyed on the fetch script so the cache busts when
  the pin moves) and the Metal addon.

- before-pack.cjs now runs on darwin. It asserts the *shipped* payload in
  electron/native/bin/darwin-<arch>/ — the directory mac.extraResources copies
  wholesale — contains the compositor addon, the ffmpeg dylibs it links, the
  whisper-stt helper, the ggml dylibs that helper links, and the
  ScreenCaptureKit helper, naming what breaks for each. It then applies the
  existing staleness check to the arch-tagged addon rather than the dev copy,
  since the arch-tagged one is what actually gets packaged.

Verified both directions: passes on a complete tree; with compositor_view.node
removed it names the addon, with libggml*.dylib removed it names the ggml
dylibs, exit 1 both times. build.yml re-parses as valid YAML and the macOS job's
step order is unchanged apart from the insertions.

NOT touched: the job's `if: false`. Its comment marks it release-branch-only for
1.8.0 shipping Windows-only, and says explicitly not to let it reach main. So
these fixes make the job correct but do not make it run — that is a release
decision, and it is now flagged in build-and-packaging.md.